<!--
---
title: Using a Service to Expose Your App
---
-->
---
title: 使用服务发布您的应用程序
---
<!DOCTYPE html>

<html lang="en">

<body>

<link href="/docs/tutorials/kubernetes-basics/public/css/styles.css" rel="stylesheet">

<div class="layout" id="top">

	<main class="content">

		<div class="row">
			<div class="col-md-8">
				<!--
    		<h3>Objectives</h3>
				<ul>
					<li>Learn about a Service in Kubernetes</li>
					<li>Understand how labels and LabelSelector objects relate to a Service</li>
					<li>Expose an application outside a Kubernetes cluster using a Service</li>
				</ul>
			-->
			<h3>目标</h3>
				<ul>
					<li>了解 Kubernetes 中的服务</li>
					<li>了解标签和标签选择器对象如何与服务相关联</li>
					<li>通过 Service 在 Kubernetes 集群外发布应用程序</li>
				</ul>
			</div>

			<div class="col-md-8">
				<!--
			<h3>Overview of Kubernetes Services</h3>

			<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/user-guide/replication-controller/#what-is-a-replicationcontroller">ReplicationController</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are fungible; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>

			<p>Enter <i>Services</i>. A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-config-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>

			<p>Although Pods each have a unique IP address, those IPs are not exposed outside the cluster without a Service. Services allow your applications to receive traffic. Services can be exposed in different ways by specifying a <code>type</code> in the ServiceSpec:</p>
			<ul>
				<li><i>ClusterIP</i> (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.</li>
				<li><i>NodePort</i> - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <code><NodeIP>:<NodePort></code>. Superset of ClusterIP.</li>
				<li><i>LoadBalancer</i> - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.</li>
				<li><i>ExternalName</i> - Exposes the Service using an arbitrary name (specified by <code>externalName</code> in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of <code>kube-dns</code>.</li>
			</ul>
			<p>More information about the different types of Services can be found in the <a href="/docs/tutorials/services/source-ip/">Using Source IP</a> tutorial. Also see <a href="/docs/concepts/services-networking/connect-applications-service">Connecting Applications with Services</a>.</p>
			<p>Additionally, note that there are some use cases with Services that involve not defining <code>selector</code> in the spec. A Service created without <code>selector</code> will also not create the corresponding Endpoints object. This allows users to manually map a Service to specific endpoints. Another possibility why there may be no selector is you are strictly using <code>type: ExternalName</code>.</p>
		-->
		<h3>Kubernetes 服务概述</h3>

			<p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> 终有一死. Pods 实际上有一个 <a href="/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>. 当工作节点死机时, 节点上运行的Pod也将丢失。 一个 <a href="/docs/user-guide/replication-controller/#what-is-a-replicationcontroller">ReplicationController</a> 可能会通过创建新的Pod以动态地将集群恢复到所需的状态，以保持您的应用程序运行。还有一种方法就是：决定是否使用具有3个副本的图像处理后端。这些副本是可替代的前端系统不应关心后端副本，即使Pod丢失并重建也不会更改。 也就是说，Kubernetes 集群中的每个 Pod 都有一个唯一的IP地址，即使在同一个节点上的 Pods 也是如此，所以此时就需要一种自动调整更改 Pod 的方法, 以便您的应用程序继续运行。输入 <i>服务</i>. Kubernetes 中的服务是一个抽象对象，它定义了一组逻辑的 Pods 和一个访问它们的策略。 服务让互相依赖的 Pod 之间的耦合松动。 服务由 YAML <a href="/docs/concepts/configuration/overview/#general-config-tips">(首选)</a> 或 JSON 定义。像所有 Kubernetes 对象一样。 针对服务的一组 Pod 通常由<i>Label选择器</i>确定（参见下文，为什么您可能希望不将 <code>选择器</code> 包含在规范中。</p>

			<p>虽然每个 Pod 都有一个唯一的 IP 地址，但是这些 IP 不会在没有服务的情况下公开在群集之外。服务允许您的应用程序接收流量。 可以通过在 ServiceSpec 中指定<code>类型</code> 以不同方式显示服务：</p>
			<ul>
				<li><i>ClusterIP</i>(默认) - 在集群中的内部IP上公开服务。此类型使服务只能从集群中访问。</li>
				<li><i>NodePort</i> —— 使用NAT在群集中每个选定的节点的同一端口上显示该服务。使用 <code><NodeIP>:<NodePort></code>可以从群集外部访问服务。建立 ClusterIP 的超集.</li>
				<li><i>LoadBalancer</i> —— 在当前云中创建外部负载平衡器(如果支持)，并为服务分配固定的外部IP。建立 NodePort 的超集。</li>
				<li><i>ExternalName</i> —— 使用任意名称显示该服务(由规范中的<code>externalName</code> 指定)，本过程通过使用该名称返回 CNAME 记录达成。无须使用代理。这种类型需要 v1.7 或更高版本的 <code>kube-dns</code>.</li>
			</ul>
			<p>有关不同类型服务的详细信息，请参见 <a href="/docs/tutorials/services/source-ip/">使用源IP</a> 教程。另请参阅 <a href="/docs/concepts/services-networking/connect-applications-service">使用服务连接应用程序</a>.</p>
			<p>另外，请注意，服务中有一些使用案例涉及在规范中不定义<code>选择器</code> 。不使用 <code>选择器</code> 创建的服务也不会创建相应的端点对象。 这允许用户手动将服务映射到特定端点。没有选择器还有可能是因为您严格地使用了 <code>type: ExternalName</code>.</p>
			</div>
			<div class="col-md-4">
				<div class="content__box content__box_lined">
					<!--
					<h3>Summary</h3>
					<ul>
						<li>Exposing Pods to external traffic</li>
						<li>Load balancing traffic across multiple Pods</li>
						<li>Using labels</li>
					</ul>
				-->
				<h3>摘要</h3>
					<ul>
						<li>对外部流量曝光 Pod </li>
						<li>跨多个 Pods 进行流量负载均衡</li>
						<li>使用标签</li>
					</ul>

				</div>
				<div class="content__box content__box_fill">
					<!--
						<p><i>A Kubernetes Service is an abstraction layer which defines a logical set of Pods and enables external traffic exposure, load balancing and service discovery for those Pods.</i></p>
					-->
					<p><i>Kubernetes 服务是一个抽象层，它定义了一组逻辑的Pods，并为这些Pods启用了外部流量曝光、负载平衡和服务发现。</i></p>
				</div>
			</div>
		</div>
		<br>

		<div class="row">
			<div class="col-md-8">
				<!--<h3>Services and Labels</h3>-->
				<h3>服务和标签</h3>
			</div>
		</div>

		<div class="row">
			<div class="col-md-8">
				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_services.svg" width="150%" height="150%"></p>
			</div>
		</div>

		<div class="row">
			<div class="col-md-8">
				<!--
				<p>A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.</p>
				<p>Services match a set of Pods using <a href="/docs/concepts/overview/working-with-objects/labels">labels and selectors</a>, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:</p>
				<ul>
					<li>Designate objects for development, test, and production</li>
					<li>Embed version tags</li>
					<li>Classify an object using tags</li>
				</ul>
-->
<p> A 服务可以跨一组 Pod 路由流量。服务是允许 Pod 在 Kubernetes 中死亡和复制而不影响应用程序的抽象层。相关 Pod 之间的发现和路由(如应用程序中的前端和后端组件)是由 Kubernetes Services 处理的。</p>
				<p> 服务使用 <a href="/docs/concepts/overview/working-with-objects/labels">标签和选择器</a>, 匹配一组 Pod，成为分组原语，此原语允许在 Kubernetes 中的对象进行逻辑运算。标签是一对附加到对象的关键/重要组，可以以多种方式使用，方式如下: </p>
				<ul>
					<li>指定用于开发、测试和生产的对象</li>
					<li>嵌入版本标签</li>
					<li>使用标签分类对象</li>
				</ul>
			</div>
			<div class="col-md-4">
				<div class="content__box content__box_fill">
					<!--
					<p><i>You can create a Service at the same time you create a Deployment by using<br><code>--expose</code> in kubectl.</i></p>
				-->
				<p><i>您可以在使用<br><code>--expose</code> 在 kubectl 中创建部署的同时创建服务.</i></p>
				</div>
			</div>
		</div>

		<br>

		<div class="row">
			<div class="col-md-8">
				<p><img src="/docs/tutorials/kubernetes-basics/public/images/module_04_labels.svg"></p>
			</div>
		</div>
		<br>
		<div class="row">
			<div class="col-md-8">
				<!--
				<p>Labels can be attached to objects at creation time or later on. They can be modified at any time. Let's expose our application now using a Service and apply some labels.</p>
			-->
			<p>标签可以在创建时或之后附加到对象后，并支持随时修改。让我们现在开始使用服务公开我们的应用程序并应用一些标签吧。</p>
			</div>
		</div>
		<br>
		<div class="row">
			<div class="col-md-12">
				<!--
				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-interactive/" role="button">Start Interactive Tutorial<span class="btn__next">›</span></a>
			-->
				<a class="btn btn-lg btn-success" href="/docs/tutorials/kubernetes-basics/expose-interactive/" role="button">启动互动教程<span class="btn__next">›</span></a>
			</div>
		</div>
	</main>
</div>

</body>
</html>
